Date: Mon, 18 Jan 93 04:30:03 PST 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #17 

To: packet-radio 


Packet-Radio Digest Mon, 18 Jan 93 Volume 93 : Issue 17 


Today's Topics: 
(none) 
BAYCOM and Linux ? 
Problems using ka9q and activeopen PPP 
rsgb gb2rs news 17th november 1993 
TS140s, MFJ Multimode TNC and LSB Distortion 
USING HANDHELDS ON PACKET 
Writing a packet client program? 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 17 Jan 93 22:51:49 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: (none) 

To: packet-radio@ucsd.edu 


Quent Johnson (quent@md.fsl.noaa.gov) said: 

What if someone sends email containing obscenities. 

What about sound files containing music? 

What about email to mailing lists -- is this considered broadcasting? 
I say: 

I'm sure the control op eithe inspects the mail (unlikely) or has a 


kill file that looks for "obsscene, indecent, or profane words" in the 
text and doesn't allow transmission if it finds one. The full part of 


97.113(d) goes futher than this though: obsscene, indecent, or profane 
words or meaning [it might be difficult to stop the later with a kill 
file is only 'clean' words are used]; and/or false or deceptive 
messages or signals [this too are more difficult to detect]". Once must 
also be wary of commerical messages (i.e look for the string "900" :-). 
THe FCC did backoff on the responsibilities of sysops who relayed 
messages in the system, the originator having the full responsibility. 
Unfortunatly the control operator of the gateway is the responsible 
person in this case. This may explain why there are very few gateways. 


Data files containing musical sounds are only musical sounds when 
played on the appropriate equipment. They don't sound like music on the 
air (just sound like packets too me) so they're not in violation of 
Part 97.113(d). Consider why this rule was put in place originally and 
you can see it can't apply to data files. This might actually become 
important with more people getting into multimedia. 


All the transmission are point to point on the ham side, so there is no 
broadcasting involved. Note to that bullitens (messages with multiple 
destinations) are allowed in the packet system and are not considered 
"broadcasts" because all transmissions involved are two way QSOs 
(between the BBSes passing the messages and the intermediate nodes). 


In general, don't under interpret the FCC regulations and don't ask the 
FCC what the rules mean, as they'll often come up with a more 
conservative ruling futher restricting experimentation in the amateur service. 


Follow ups are best directed to rec.radio.ham.policy 


72/73 Kevin, N7WIM / G8UDP 
a-kevinp@microsoft.com 


Date: 17 Jan 1993 21:37:07 GMT 

From: sdd.hp.com!spool.mu.edu!yale.edu!ira.uka.de!rz.uni-karlsruhe.de!aifbtornado! 
rza@network.UCSD.EDU 

Subject: BAYCOM and Linux ? 

To: packet-radio@ucsd.edu 


Hello all, 
Just one Question: Did anyone succeed in running a BAYCOM Modem/TNC under 
Linux ? (My baycom-Modem is the only reason for me to still have a dos 


bootdisk) . 


Perhaps I can write the required software of my own, where can I get more 
info on the way the baycom piece works? 


Any help will be greatly appreciated. 


Regards, 

Ralf 

Ralf Zabka email: zabka@infpav4.kfk.de 
Haid und Neu Str. 12 or rza@aifb.uni-karlsruhe.de 
W-7500 Karlsruhe 1 phone: +49 721 69 72 82 


Date: Sun, 17 Jan 1993 18:29:07 GMT 

From: swrinde! gatech! concert! rock! cole@network.UCSD.EDU 
Subject: Problems using ka9q and activeopen PPP 

To: packet-radio@ucsd.edu 


Note: this message cross-posted to both comp.protocols.ppp AND 
rec.radio.amateur.packet! ! 


Greetings! 


I'm attempting to coax the latest release of KA9Q to dial my workstation 
(running dp-2.2) and initiate a PPP link. I've encountered two rather 
significant obstacles: 


1) ‘ppp ppO lcp|ipcp open active' does nothing. The default for dp-2.2 is 
to open a passive dialup session. The two boxes could sit around forever 
and never talk to each other. I've even tried PPP between two KA9Q boxes, 
one active, one passive. Still zippo. What am I missing? 


If I open passive in KA9Q after initiating an active session on the 
workstation, that at least gets the boxes talking, but the link never fully 
comes up. It apparently negotiates LCP, passes the IPCP addresses, then 
gets stuck, the workstation sending the same packet over and over, KA9Q 
responding with what looks to be an ACK. 


2) How in the world does the new dial command work?!?!? I seem to recall 
an article regarding Phil's link-redialing enhancements, but I'm perplexed 
as to what needs to be done. I'm used to ‘dial ppO dialer.pp0' 


Please pardon my ignorance, but I'm new to PPP and it's configuration. Any 
and all help will be greatly appreciated! 


Thanks, 
Derrick 


"Have you ever tried to clean bits of chow mein out of a keyboard? It isn't 
pretty." 
-- unknown 


Date: 18 Jan 93 11:12:15 GMT 

From: dog.ee.lbl.gov!overload.1lbl.gov!agate!doc.ic.ac.uk!uknet!edcastle!wilde! 
graham@network.UCSD.EDU 

Subject: rsgb gb2rs news 17th november 1993 

To: packet-radio@ucsd.edu 


ted@tedb.demon.co.uk (Edward Batts) writes: 
>Good morning. It's Sunday the 17th of January and here is the GB2RS news 
>broadcast, prepared by the Radio Society of Great Britain. 


Something wrong with the Subject line here I think. :-) 


Graham Rule 


Date: 17 Jan 93 20:32:00 GMT 

From: news-mail-gateway@ucsd.edu 

Subject: TS140s, MFI Multimode TNC and LSB Distortion 
To: packet-radio@ucsd.edu 


I would like to inquire if anyone on the list has had a similar problem to the 
following: 


A friend is using a TS140s and a MFJ Multi-Mode TNC connected via the 
Accessory port. Like previous communications about the ts850, 950, 690 

( mine) he is suffering from audio distortion if he leaves the TNC 
connected when using SSB. I have solved tha problem in the past on the 690s 
by effective grounding of my PK232MBX to the 690s ( thanks Dick, KD5VU). 

My questions are: is the acc port on the 140s the same as the 850, 450, 

690 etc or different? and - Has any one else had a similar setup with 

a MFJ unit and solved it. He must stay with AFSK since I believe the 

140 does not permit FSK operation. 


Replies may be sent to the list ( since the information would be 
of value to those who still disconnect their TNCs prior to SSB 


operation) or direct to : 


SEELER@UPEI.CA 


Thank you for your help in this matter ( and for solving the Kenwood 
floating ground problem once again ). 


David Seeler, 

University of Prince Edward Island, 
SEELER@UPEI.CA 
VY2DCS@VE1AIC.PE.CAN.NA 


Date: 15 Jan 93 05:21:03 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: USING HANDHELDS ON PACKET 
To: packet-radio@ucsd.edu 


Date: Thu Jan 14 12:36:28 1993 
Message-Id: <2439@GB7BIL> 

From: G6LOH @ GB7BIL 

Reply-To: G6LOH @ GB7BIL.#27.GBR.EU 
To: PRAGA @ PI8VNW 

Subject: USING HANDHELDS ON PACKET 


someone was asking for a transformer PTT interface for Icom handhelds. 
Well here is the file from the GB7BIL mods database 


Icom Handhelds on packet 


TNC RIG 

PTT wennen----- 4.7K-------- TIP OF SMALL JACK 
TX AUDIO------ @.1MF------- TIP OF SMALL JACK 
GROUND-------------------- BODY OF BOTH JACKS 
RX AUDIO------------------ TIP OF LARGE JACK 


This arrangement works with most TNC2 type clones, but it has not been tried 
on the PK88. 


Another possibility would be to use a 1 to 1 audio isolating transformer. 
This is a suggestion on how to connect it up: 


RX AUDIO--------- TIP OF LARGE JACK 


GROUND----------- BODY OF LARGE JACK 


GROUND----------- TRANSFORMER PRIMARY 
TX AUDIO--------- TRANSFORMER PRIMARY 
PU Tas-ses+se5-58- TRANSFORMER SECONDARY 
TRANSFORMER SECONDARY--------- TIP OF SMALL JACK 


When the PTT line goes low, it makes the Tx connection for the handheld. 
Having said that, on the IC24 there is a ring on the small jack that carries 
+5v and you must be carefull not to short this by using a mono jack. 


Julian G6LOH @ GB7BIL 


PLEASE reply to the list, NOT to the From: address 
because this mail is sent through a one-way gateway! 


Date: Sun, 17 Jan 1993 19:29:21 GMT 

From: usc!howland.reston.ans.net! zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu! 
ucselx!steer!waffle@network.UCSD.EDU 

Subject: Writing a packet client program? 

To: packet-radio@ucsd.edu 


I'm interested in writing a client program for packet. That is, instead of 
using my packet controller's usual maildrop, I want software on my PC to 


talk to it. I know that software exists already for this -- bbses and 
whatnot -- but I'm interested in writing my own, in C, perhaps a game or 
something. 


I'm not too familiar with the AX.25 protocol (at least on a system level 
where a program needs to make sence out of it all!) and I'd like some 
information about what needs to be handled, how to send actual stuff 

over packet via my own program, etc. Has anyone done this who will give me 
some pointers? Or do some docs exist on the net that can help? 


Thanks in advance 
Kevin kc6gwq - waffle@steer.sdsu.edu 


Date: Mon, 18 Jan 1993 00:39:12 GMT 
From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <1993Jan6.093218.27598@qualcomm.com>, <1j9hqcINN9rf@matt.ksu.ksu.edu>, 


<1993Jan16.201038.1158@sbcs.sunysb.edu> 
Subject : Re: CDMA Packet Radio (WAS Re: Who do repeater coordinators represent?) 


In article <1993Jan16.201038.1158@sbcs.sunysb.edu> rick@cs.sunysb.edu (Richard 
Spanbauer) writes: 


> The main hitch with CDMA (code division multiple access) is that 
> the amateur radio service is allowed to use only three spreading 
> codes. Is there work being done towards relaxing the regulations 
> on use of spreading codes? 


I'm sure if there was a real need to change the rules, the FCC would 
be willing to change them. There's an STA in existence right now 
that waives this requirement. 


Of course, there are still all the other restrictions on amateur 
radio, particularly the content rules, that would be much more 
difficult to change. That's why I think Part 15 (and possibly 
user-provided "data PCS" on 1.8 Ghz) is where the future of packet 
radio lies. 


Phil 


Date: Mon, 18 Jan 1993 00:36:27 GMT 
From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <1993Jan4.144520.19597@ultb.isc.rit.edu>, 
<1993Jan6.093218.27598@qualcomm.com>, <1j9hqcINN9rf@matt.ksu.ksu.edu> 
Subject : Re: CDMA Packet Radio (WAS Re: Who do repeater coordinators represent?) 


In article <1j9hqcINN9rf@matt.ksu.ksu.edu> steve@matt.ksu.ksu.edu (Steve 
Schallehn) writes: 

>I agree that CDMA would also be great for amateur radio, 

>but I thought CDMA is patented by Qualcomm. What effects will the 
>patent have on developing CDMA packet networks? 


Generic, basic CDMA (i.e., multiple spread spectrum transmitters 
sharing the spectrum) has been around for a long time -- since World 
War 2 -- so any patents on it have long since expired. Qualcomm's 
patents cover only some very specific implementation details on 
applying CDMA to cellular telephony, particularly the closed-loop 
power control scheme. 


I can't speak for management, but I can say that the three senior 
engineering VPs are all hams, and have spoken very favorably of the 
possibility of applying our CDMA system to ham radio. Of course, we 


currently have our hands more than full finishing the commercial 
system and getting it standardized and deployed by the industry... 


Phil 


Date: Mon, 18 Jan 1993 00:28:59 GMT 
From: qualcom.qualcomm.com!servo.qualcomm.com! karn@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <jstark.726853484@mcshh.hanse.de>, <9116@lee.SEAS.UCLA.EDU>, 
<ashok.238.727148540@biochemistry.cwru.edu> 
Subject : Re: Nos (KA9Q,PAQGRI...) 


The latest versions of NOS that I've released have their own built-in 
terminal emulation; they no longer use ansi.sys or whatever. 

The very latest version emulates a 24x80 ansi display, with most (but 
I won't guarantee all) vt-100 functions as well. The generic "ansi" 
termcap entry seems to work well. 

I haven't done the vt100 keyboard yet, but that's on my list. 

Phil 


End of Packet-Radio Digest V93 #17 
KKKKKKKKKKKKKKKAKKKKKKKKKKRKR KAKA 


